

<!DOCTYPE html>
<html lang="zh-CN" data-default-color-scheme=auto>



<head>
  <meta charset="UTF-8">
  <link rel="apple-touch-icon" sizes="76x76" href="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/IKKIS_LOGO.png">
  <link rel="icon" href="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/IKKIS_LOGO.png">
  <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=5.0, shrink-to-fit=no">
  <meta http-equiv="x-ua-compatible" content="ie=edge">
  
  <meta name="theme-color" content="#2f4154">
  <meta name="author" content="Ikki">
  <meta name="keywords" content="">
  
    <meta name="description" content="1.HTTP 基本概念1.1 HTTP 是什么？ HTTP 是超文本传输协议，它可以拆成三个部分： 超文本 HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。   传输 HTTP 是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。 在 HTTP 里，需要中间人遵从 HTTP 协议，只要不打扰基本的数据传输，就可以添加任意额外的">
<meta property="og:type" content="article">
<meta property="og:title" content="HTTP协议">
<meta property="og:url" content="http://81.68.132.127/2022/10/07/network/http%E5%8D%8F%E8%AE%AE/index.html">
<meta property="og:site_name" content="IKKI">
<meta property="og:description" content="1.HTTP 基本概念1.1 HTTP 是什么？ HTTP 是超文本传输协议，它可以拆成三个部分： 超文本 HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。   传输 HTTP 是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。 在 HTTP 里，需要中间人遵从 HTTP 协议，只要不打扰基本的数据传输，就可以添加任意额外的">
<meta property="og:locale" content="zh_CN">
<meta property="og:image" content="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/beijing/iTab-1kz6jg.jpeg">
<meta property="article:published_time" content="2022-10-07T11:22:15.000Z">
<meta property="article:modified_time" content="2022-10-07T11:58:04.948Z">
<meta property="article:author" content="Ikki">
<meta property="article:tag" content="网络知识">
<meta property="article:tag" content="HTTP">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:image" content="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/beijing/iTab-1kz6jg.jpeg">
  
  
    <meta name="referrer" content="no-referrer-when-downgrade">
  
  
  <title>HTTP协议 - IKKI</title>

  <link  rel="stylesheet" href="https://lib.baomitu.com/twitter-bootstrap/4.6.1/css/bootstrap.min.css" />



  <link  rel="stylesheet" href="https://lib.baomitu.com/github-markdown-css/4.0.0/github-markdown.min.css" />

  <link  rel="stylesheet" href="https://lib.baomitu.com/hint.css/2.7.0/hint.min.css" />

  <link  rel="stylesheet" href="https://lib.baomitu.com/fancybox/3.5.7/jquery.fancybox.min.css" />



<!-- 主题依赖的图标库，不要自行修改 -->
<!-- Do not modify the link that theme dependent icons -->

<link rel="stylesheet" href="//at.alicdn.com/t/font_1749284_hj8rtnfg7um.css">



<link rel="stylesheet" href="//at.alicdn.com/t/font_1736178_lbnruvf0jn.css">


<link  rel="stylesheet" href="/css/main.css" />


  <link id="highlight-css" rel="stylesheet" href="/css/highlight.css" />
  
    <link id="highlight-css-dark" rel="stylesheet" href="/css/highlight-dark.css" />
  



  
<link rel="stylesheet" href="/fluid/css/fluid-extention.css">
<link rel="stylesheet" href="/fluid/css/nihao.css">



  <script id="fluid-configs">
    var Fluid = window.Fluid || {};
    Fluid.ctx = Object.assign({}, Fluid.ctx)
    var CONFIG = {"hostname":"81.68.132.127","root":"/","version":"1.9.3","typing":{"enable":true,"typeSpeed":70,"cursorChar":"_","loop":false,"scope":[]},"anchorjs":{"enable":true,"element":"h1,h2,h3,h4,h5,h6","placement":"left","visible":"hover","icon":""},"progressbar":{"enable":true,"height_px":3,"color":"#29d","options":{"showSpinner":false,"trickleSpeed":100}},"code_language":{"enable":true,"default":"TEXT"},"copy_btn":true,"image_caption":{"enable":true},"image_zoom":{"enable":true,"img_url_replace":["",""]},"toc":{"enable":true,"placement":"left","headingSelector":"h1,h2,h3,h4,h5,h6","collapseDepth":3},"lazyload":{"enable":true,"loading_img":"https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif","onlypost":false,"offset_factor":2},"web_analytics":{"enable":false,"follow_dnt":true,"baidu":null,"google":null,"gtag":null,"tencent":{"sid":null,"cid":null},"woyaola":null,"cnzz":null,"leancloud":{"app_id":null,"app_key":null,"server_url":null,"path":"window.location.pathname","ignore_local":false}},"search_path":"/local-search.xml"};

    if (CONFIG.web_analytics.follow_dnt) {
      var dntVal = navigator.doNotTrack || window.doNotTrack || navigator.msDoNotTrack;
      Fluid.ctx.dnt = dntVal && (dntVal.startsWith('1') || dntVal.startsWith('yes') || dntVal.startsWith('on'));
    }
  </script>
  <script  src="/js/utils.js" ></script>
  <script  src="/js/color-schema.js" ></script>
  


  
<meta name="generator" content="Hexo 5.4.2"></head>


<body>
  

  <header>
    

<div class="header-inner" style="height: 100vh;">
  <nav id="navbar" class="navbar fixed-top  navbar-expand-lg navbar-dark scrolling-navbar">
  <div class="container">
    <a class="navbar-brand" href="/">
      <strong>Ikki-BUG制造者</strong>
    </a>

    <button id="navbar-toggler-btn" class="navbar-toggler" type="button" data-toggle="collapse"
            data-target="#navbarSupportedContent"
            aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation">
      <div class="animated-icon"><span></span><span></span><span></span></div>
    </button>

    <!-- Collapsible content -->
    <div class="collapse navbar-collapse" id="navbarSupportedContent">
      <ul class="navbar-nav ml-auto text-center">
        
          
          
          
          
            <li class="nav-item">
              <a class="nav-link" href="/">
                <i class="iconfont icon-home-fill"></i>
                首页
              </a>
            </li>
          
        
          
          
          
          
            <li class="nav-item">
              <a class="nav-link" href="/archives/">
                <i class="iconfont icon-archive-fill"></i>
                归档
              </a>
            </li>
          
        
          
          
          
          
            <li class="nav-item">
              <a class="nav-link" href="/categories/">
                <i class="iconfont icon-category-fill"></i>
                分类
              </a>
            </li>
          
        
          
          
          
          
            <li class="nav-item">
              <a class="nav-link" href="/tags/">
                <i class="iconfont icon-tags-fill"></i>
                标签
              </a>
            </li>
          
        
          
          
          
          
            <li class="nav-item">
              <a class="nav-link" href="/about/">
                <i class="iconfont icon-user-fill"></i>
                关于
              </a>
            </li>
          
        
        
          <li class="nav-item" id="search-btn">
            <a class="nav-link" target="_self" href="javascript:;" data-toggle="modal" data-target="#modalSearch" aria-label="Search">
              &nbsp;<i class="iconfont icon-search"></i>&nbsp;
            </a>
          </li>
          
        
        
          <li class="nav-item" id="color-toggle-btn">
            <a class="nav-link" target="_self" href="javascript:;" aria-label="Color Toggle">&nbsp;<i
                class="iconfont icon-dark" id="color-toggle-icon"></i>&nbsp;</a>
          </li>
        
      </ul>
    </div>
  </div>
</nav>

  

<div id="banner" class="banner" parallax=true
     style="background: url('http://image.ikki0603.cn') no-repeat center center; background-size: cover;">
  <div class="full-bg-img">
    <div class="mask flex-center" style="background-color: rgba(0, 0, 0, 0.3)">
      <div class="banner-text text-center fade-in-up">
        <div class="h2">
          
            <span id="subtitle" data-typed-text="HTTP协议"></span>
          
        </div>

        
          
  <div class="mt-3">
    
    
      <span class="post-meta">
        <i class="iconfont icon-date-fill" aria-hidden="true"></i>
        <time datetime="2022-10-07 19:22" pubdate>
          2022年10月7日 晚上
        </time>
      </span>
    
  </div>

  <div class="mt-1">
    
      <span class="post-meta mr-2">
        <i class="iconfont icon-chart"></i>
        
          15k 字
        
      </span>
    

    
      <span class="post-meta mr-2">
        <i class="iconfont icon-clock-fill"></i>
        
        
        
          127 分钟
        
      </span>
    

    
    
      
        <span id="busuanzi_container_page_pv" style="display: none">
          <i class="iconfont icon-eye" aria-hidden="true"></i>
          <span id="busuanzi_value_page_pv"></span> 次
        </span>
        
      
    
  </div>


        
      </div>

      
        <div class="scroll-down-bar">
          <i class="iconfont icon-arrowdown"></i>
        </div>
      
    </div>
  </div>
</div>

</div>

  </header>

  <main>
    
      

<div class="container-fluid nopadding-x">
  <div class="row nomargin-x">
    <div class="side-col d-none d-lg-block col-lg-2">
      
  <aside class="sidebar" style="padding-left: 2rem; margin-right: -1rem">
    <div id="toc">
  <p class="toc-header"><i class="iconfont icon-list"></i>&nbsp;目录</p>
  <div class="toc-body" id="toc-body"></div>
</div>



  </aside>


    </div>

    <div class="col-lg-8 nopadding-x-md">
      <div class="container nopadding-x-md" id="board-ctn">
        <div id="board">
          <article class="post-content mx-auto">
            <!-- SEO header -->
            <h1 style="display: none">HTTP协议</h1>
            
              <p class="note note-info">
                
                  
                    本文最后更新于：2022年10月7日 晚上
                  
                
              </p>
            
            
              <div class="markdown-body">
                
                <h1 id="1-HTTP-基本概念"><a href="#1-HTTP-基本概念" class="headerlink" title="1.HTTP 基本概念"></a>1.HTTP 基本概念</h1><h2 id="1-1-HTTP-是什么？"><a href="#1-1-HTTP-是什么？" class="headerlink" title="1.1 HTTP 是什么？"></a>1.1 HTTP 是什么？</h2><ul>
<li>HTTP 是超文本传输协议，它可以拆成三个部分：<ul>
<li>超文本<ul>
<li>HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。</li>
</ul>
</li>
<li>传输<ul>
<li>HTTP 是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。</li>
<li>在 HTTP 里，需要中间人遵从 HTTP 协议，只要不打扰基本的数据传输，就可以添加任意额外的东西。<br><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-27-00.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></li>
</ul>
</li>
<li>协议<ul>
<li>HTTP 协议是一个双向协议。</li>
<li>HTTP 是一个用在计算机世界里的协议。它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范（两个以上的参与者），以及相关的各种控制和错误处理方式（行为约定和规范）。<br><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-24-41.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></li>
</ul>
</li>
</ul>
</li>
</ul>
<h2 id="1-2-HTTP-常见的状态码有哪些？"><a href="#1-2-HTTP-常见的状态码有哪些？" class="headerlink" title="1.2 HTTP 常见的状态码有哪些？"></a>1.2 HTTP 常见的状态码有哪些？</h2><p><code>1xx</code> 类状态码属于<strong>提示信息</strong>，是协议处理中的一种中间状态，实际用到的比较少。</p>
<p><code>2xx</code> 类状态码表示服务器<strong>成功</strong>处理了客户端的请求，也是我们最愿意看到的状态。</p>
<ul>
<li><p>「<strong>200 OK</strong>」是最常见的成功状态码，表示一切正常。如果是非 <code>HEAD</code> 请求，服务器返回的响应头都会有 body 数据。</p>
</li>
<li><p>「<strong>204 No Content</strong>」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。</p>
</li>
<li><p>「<strong>206 Partial Content</strong>」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。</p>
</li>
</ul>
<p><code>3xx</code> 类状态码表示客户端请求的资源发送了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是<strong>重定向</strong>。 </p>
<ul>
<li><p>「<strong>301 Moved Permanently</strong>」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。</p>
</li>
<li><p>「<strong>302 Found</strong>」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。</p>
</li>
</ul>
<p>301 和 302 都会在响应头里使用字段 <code>Location</code>，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。</p>
<ul>
<li>「<strong>304 Not Modified</strong>」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。</li>
</ul>
<p><code>4xx</code> 类状态码表示客户端发送的<strong>报文有误</strong>，服务器无法处理，也就是错误码的含义。</p>
<ul>
<li><p>「<strong>400 Bad Request</strong>」表示客户端请求的报文有错误，但只是个笼统的错误。</p>
</li>
<li><p>「<strong>403 Forbidden</strong>」表示服务器禁止访问资源，并不是客户端的请求出错。</p>
</li>
<li><p>「<strong>404 Not Found</strong>」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。</p>
</li>
</ul>
<p><code>5xx</code> 类状态码表示客户端请求报文正确，但是<strong>服务器处理时内部发生了错误</strong>，属于服务器端的错误码。</p>
<ul>
<li><p>「<strong>500 Internal Server Error</strong>」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。</p>
</li>
<li><p>「<strong>501 Not Implemented</strong>」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。</p>
</li>
<li><p>「<strong>502 Bad Gateway</strong>」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。</p>
</li>
<li><p>「<strong>503 Service Unavailable</strong>」表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。</p>
</li>
</ul>
<h2 id="1-3-GET-与-POST"><a href="#1-3-GET-与-POST" class="headerlink" title="1.3 GET 与 POST"></a>1.3 GET 与 POST</h2><p>根据 RFC 规范，<strong>GET 的语义是从服务器获取指定的资源</strong>，这个资源可以是静态的文本、页面、图片视频等。GET 请求的参数位置一般是写在 URL 中，URL 规定只能支持 ASCII，所以 GET 请求的参数只允许 ASCII 字符 ，而且浏览器会对 URL 的长度有限制（HTTP协议本身对 URL长度并没有做任何规定）。</p>
<p>比如，你打开我的文章，浏览器就会发送 GET 请求给服务器，服务器就会返回文章的所有文字及资源。</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-40-11.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>根据 RFC 规范，<strong>POST 的语义是根据请求负荷（报文body）对指定的资源做出处理</strong>，具体的处理方式视资源类型而不同。POST 请求携带数据的位置一般是写在报文 body 中， body 中的数据可以是任意格式的数据，只要客户端与服务端协商好即可，而且浏览器不会对 body 大小做限制。</p>
<p>比如，你在我文章底部，敲入了留言后点击「提交」（<strong>暗示你们留言</strong>），浏览器就会执行一次 POST 请求，把你的留言文字放进了报文 body 里，然后拼接好 POST 请求头，通过 TCP 协议发送给服务器。</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-40-28.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<h3 id="1-3-1-GET-和-POST-方法都是安全和幂等的吗？"><a href="#1-3-1-GET-和-POST-方法都是安全和幂等的吗？" class="headerlink" title="1.3.1 GET 和 POST 方法都是安全和幂等的吗？"></a>1.3.1 GET 和 POST 方法都是安全和幂等的吗？</h3><p>先说明下安全和幂等的概念：</p>
<ul>
<li>在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。</li>
<li>所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。</li>
</ul>
<p>如果从 RFC 规范定义的语义来看： </p>
<ul>
<li><strong>GET 方法就是安全且幂等的</strong>，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。所以，<strong>可以对 GET 请求的数据做缓存，这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），而且在浏览器中 GET 请求可以保存位书签</strong>。</li>
<li><strong>POST</strong> 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是<strong>不安全</strong>的，且多次提交数据就会创建多个资源，所以<strong>不是幂等</strong>的。所以，<strong>浏览器一般不会缓存 POST 请求，也不能把 POST 请求保存为书签</strong>。</li>
</ul>
<p>做个简要的小结。</p>
<p>GET 的语义是请求获取指定的资源。GET 方法是安全、幂等、可被缓存的。</p>
<p>POST 的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 不安全，不幂等，（大部分实现）不可缓存。</p>
<p>注意， 上面是从 RFC 规范定义的语义来分析的。</p>
<p>但是实际过程中，开发者不一定会按照 RFC 规范定义的语义来实现 GET 和 POST 方法。比如：</p>
<ul>
<li>可以用 GET 方法实现新增或删除数据的请求，这样实现的 GET 方法自然就不是安全和幂等。</li>
<li>可以用 POST 方法实现查询数据的请求，这样实现的  POST 方法自然就是安全和幂等。</li>
</ul>
<p>曾经有个笑话，有人写了个博客，删除博客用的是GET请求，他觉得没人访问就连鉴权都没做。然后Google服务器爬虫爬了一遍，他所有博文就没了。。。</p>
<p>如果「安全」放入概念是指信息是否会被泄漏的话，虽然 POST 用 body 传输数据，而 GET 用 URL 传输，这样数据会在浏览器地址拦容易看到，但是并不能说 GET 不如 POST 安全的。</p>
<p>因为 HTTP 传输的内容都是明文的，虽然在浏览器地址拦看不到 POST 提交的 body 数据，但是只要抓个包就都能看到了。</p>
<p>所以，要避免传输过程中数据被窃取，就要使用 HTTPS 协议，这样所有 HTTP 的数据都会被加密传输。</p>
<blockquote>
<p>GET 请求可以带 body 吗？</p>
</blockquote>
<p>RFC 规范并没有规定 GET 请求不能带 body 的。理论上，任何请求都可以带 body 的。只是因为 RFC 规范定义的 GET 请求是获取资源，所以根据这个语义不需要用到 body。</p>
<p>另外，URL 中的查询参数也不是 GET 所独有的，POST 请求的 URL 中也可以有参数的。</p>
<h2 id="1-4-HTTP-缓存技术"><a href="#1-4-HTTP-缓存技术" class="headerlink" title="1.4 HTTP 缓存技术"></a>1.4 HTTP 缓存技术</h2><h3 id="1-4-1-HTTP-缓存有哪些实现方式？"><a href="#1-4-1-HTTP-缓存有哪些实现方式？" class="headerlink" title="1.4.1 HTTP 缓存有哪些实现方式？"></a>1.4.1 HTTP 缓存有哪些实现方式？</h3><p>对于一些具有重复性的 HTTP 请求，比如每次请求得到的数据都一样的，我们可以把这对「请求-响应」的数据都<strong>缓存在本地</strong>，那么下次就直接读取本地的数据，不必在通过网络获取服务器的响应了，这样的话 HTTP/1.1 的性能肯定肉眼可见的提升。</p>
<p>所以，避免发送 HTTP 请求的方法就是通过<strong>缓存技术</strong>，HTTP 设计者早在之前就考虑到了这点，因此 HTTP 协议的头部有不少是针对缓存的字段。</p>
<p>HTTP 缓存有两种实现方式，分别是<strong>强制缓存和协商缓存</strong>。</p>
<h3 id="1-4-2-什么是强制缓存？"><a href="#1-4-2-什么是强制缓存？" class="headerlink" title="1.4.2 什么是强制缓存？"></a>1.4.2 什么是强制缓存？</h3><p>强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。</p>
<p>如下图中，返回的是 200 状态码，但在 size 项中标识的是 from disk cache，就是使用了强制缓存。</p>
<p><img src="https://img-blog.csdnimg.cn/1cb6bc37597e4af8adfef412bfc57a42.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：</p>
<ul>
<li><code>Cache-Control</code>， 是一个相对时间；</li>
<li><code>Expires</code>，是一个绝对时间；</li>
</ul>
<p>如果 HTTP 响应头部同时有 Cache-Control 和 Expires 字段的话，<strong>Cache-Control的优先级高于 Expires</strong> 。</p>
<p>Cache-control 选项更多一些，设置更加精细，所以建议使用 Cache-Control 来实现强缓存。具体的实现流程如下：</p>
<ul>
<li>当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小；</li>
<li>浏览器再次请求访问服务器中的该资源时，会先<strong>通过请求资源的时间与 Cache-Control 中设置的过期时间大小，来计算出该资源是否过期</strong>，如果没有，则使用该缓存，否则重新请求服务器；</li>
<li>服务器再次收到请求后，会再次更新 Response 头部的 Cache-Control。</li>
</ul>
<p>Cache-Control 服务端参数：</p>
<ul>
<li>max-age: 在多少秒内有效，是一个相对时间，这样比Expires具体的时间就更精确了。</li>
<li>s-maxage: 就是用于表示 cache 服务器上（比如 cache CDN，缓存代理服务器）的缓存的有效时间的，并只对 public 缓存有效。</li>
<li>no-cache：不使用本地强缓存。需要使用缓存协商。</li>
<li>no-store：直接禁止浏览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。</li>
<li>public：可以被所有的用户缓存，包括终端用户和中间代理服务器。</li>
<li>private：只能被终端用户的浏览器缓存，不允许中间缓存代理进行缓存，默认的。<br>Cache-Control 客户端参数：</li>
<li>max-stale: 5 表示客户端到代理服务器上拿缓存的时候，即使代理缓存过期了也不要紧，只要过期时间在 5 秒之内，还是可以从代理中获取的。</li>
<li>min-fresh: 5 表示代理缓存需要一定的新鲜度，不要等到缓存刚好到期再拿，一定要在到期前 5 秒之前的时间拿，否则拿不到。</li>
<li>only-if-cached 这个字段加上后表示客户端只会接受代理缓存，而不会接受源服务器的响应。如果代理缓存无效，则直接返回 504（Gateway Timeout）。</li>
</ul>
<h3 id="1-4-3-什么是协商缓存？"><a href="#1-4-3-什么是协商缓存？" class="headerlink" title="1.4.3 什么是协商缓存？"></a>1.4.3 什么是协商缓存？</h3><p>当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是 <code>304</code>，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-42-23.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload><br><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-08-09-09-24-34.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>上图就是一个协商缓存的过程，所以<strong>协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存</strong>。</p>
<p>协商缓存可以基于两种头部来实现。</p>
<p>第一种：请求头部中的 <code>If-Modified-Since</code> 字段与响应头部中的 <code>Last-Modified</code> 字段实现，这两个字段的意思是：</p>
<ul>
<li><p>响应头部中的 <code>Last-Modified</code>：标示这个响应资源的最后修改时间；</p>
</li>
<li><p>请求头部中的 <code>If-Modified-Since</code>：当资源过期了，发现响应头中具有 Last-Modified 声明，则再次发起请求的时候带上 Last-Modified 的时间，服务器收到请求后发现有 If-Modified-Since 则与被请求资源的最后修改时间进行对比（Last-Modified），如果最后修改时间较新（大），说明资源又被改过，则返回最新资源，HTTP 200 OK；如果最后修改时间较旧（小），说明资源无新修改，响应 HTTP 304 走缓存。</p>
</li>
<li><p>缺点：</p>
<ul>
<li>Last-Modified 过期时间只能精确到秒。如果在同一秒既修改了文件又获取文件，客户端是获取不到最新文件的。</li>
</ul>
</li>
</ul>
<p>第二种：请求头部中的 <code>If-None-Match</code> 字段与响应头部中的 <code>ETag</code> 字段，这两个字段的意思是：</p>
<ul>
<li>响应头部中 <code>Etag</code>：唯一标识响应资源；</li>
<li>请求头部中的 <code>If-None-Match</code>：当资源过期时，浏览器发现响应头里有 Etag，则再次向服务器发起请求时，会将请求头If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有变化返回 304，如果资源变化了返回 200。</li>
</ul>
<p>第一种实现方式是基于时间实现的，第二种实现方式是基于一个唯一标识实现的，相对来说后者可以更加准确地判断文件内容是否被修改，避免由于时间篡改导致的不可靠问题。</p>
<p>如果 HTTP 响应头部同时有 Etag 和 Last-Modified 字段的时候， Etag 的优先级更高，也就是先会判断 Etag 是否变化了，如果 Etag 没有变化，然后再看  Last-Modified。</p>
<p>注意，<strong>协商缓存这两个字段都需要配合强制缓存中 Cache-control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求</strong>。</p>
<p><img src="https://img-blog.csdnimg.cn/d92026ce085b401c95cf02b7ce9b7fae.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>使用 ETag 字段实现的协商缓存的过程如下；</p>
<ul>
<li>当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 ETag 唯一标识，这个唯一标识的值是根据当前请求的资源生成的；</li>
<li>当浏览器再次请求访问服务器中的该资源时，首先会先检查强制缓存是否过期，如果没有过期，则直接使用本地缓存；如果缓存过期了，会在 Request 头部加上 If-None-Match 字段，该字段的值就是 ETag 唯一标识；</li>
<li>服务器再次收到请求后，<strong>会根据请求中的 If-None-Match 值与当前请求的资源生成的唯一标识进行比较</strong>：<ul>
<li><strong>如果值相等，则返回 304 Not Modified，不会返回资源</strong>；</li>
<li>如果不相等，则返回 200 状态码和返回资源，并在 Response 头部加上新的 ETag 唯一标识；</li>
</ul>
</li>
<li>如果浏览器收到 304 的请求响应状态码，则会从本地缓存中加载资源，否则更新资源。</li>
</ul>
<h1 id="1-4-4-缓存失效问题"><a href="#1-4-4-缓存失效问题" class="headerlink" title="1.4.4 缓存失效问题"></a>1.4.4 缓存失效问题</h1><ul>
<li>老方案<ul>
<li>老方案通过人工自己修改文件名或者在文件名后带上版本号、时间戳，这样客户端就会当新文件请求并使用，之前的强缓存就算在有效期内也会失效。<br><code>&lt;script src=&quot;http://randy.js?version=1.1.1&gt; &lt;/script&gt;</code></li>
</ul>
</li>
<li>新方案<ul>
<li>在现在的构建阶段基本上都不需要人工操作了，都是使用构建工具比如Wbpack、Gulp、Grunt等构建工具自动构建。</li>
<li>比如在使用Webpack构建的时候，会根据文件名或文件内容自动计算hash值来给文件命名，当内容或文件名发生改变的时候，构建出来的文件名也一定会不一样，这样也解决了强缓存还在有效期内的问题。</li>
</ul>
</li>
</ul>
<h1 id="1-4-5-缓存到底存在哪？"><a href="#1-4-5-缓存到底存在哪？" class="headerlink" title="1.4.5 缓存到底存在哪？"></a>1.4.5 缓存到底存在哪？</h1><p>按缓存位置分类我们可以分为memory cache、disk cache、Service Worker三类，我们可以在 Chrome 的开发者工具中，Network -&gt; Size 一列看到一个请求最终的处理方式：如果是大小 (多少 K， 多少 M 等) 就表示是网络请求，否则会列出 from memory cache、from disk cache、from ServiceWorker就表示命中了缓存。</p>
<ul>
<li>memory cache 是内存中的缓存，(与之相对 disk cache 就是硬盘上的缓存)。按照操作系统的常理：先读内存，再读硬盘。</li>
<li>disk cache 也叫 HTTP cache，顾名思义是存储在硬盘上的缓存，因此它是持久存储的，是实际存在于文件系统中的。而且它允许相同的资源在跨会话，甚至跨站点的情况下使用，例如两个站点都使用了同一张图片。</li>
<li>上述的缓存策略以及缓存/读取/失效的动作都是由浏览器内部判断进行的，我们只能设置响应头的某些字段来告诉浏览器，而不能自己操作。service work给予了我们另外一种更加灵活，可以直接的操作方式。</li>
<li>我们可以从 Chrome 的 Application找到Service Workers。这个缓存是永久性的，即关闭 TAB 或者浏览器，下次打开依然还在(而 memory cache 不是)。有两种情况会导致这个缓存中的资源被清除：手动调用 API cache.delete(resource) 或者容量超过限制，被浏览器全部清空。</li>
</ul>
<h2 id="1-5-HTTP-特性"><a href="#1-5-HTTP-特性" class="headerlink" title="1.5 HTTP 特性"></a>1.5 HTTP 特性</h2><h3 id="1-5-1-HTTP（1-1）-的优点有哪些？"><a href="#1-5-1-HTTP（1-1）-的优点有哪些？" class="headerlink" title="1.5.1 HTTP（1.1） 的优点有哪些？"></a>1.5.1 HTTP（1.1） 的优点有哪些？</h3><p>HTTP 最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。</p>
<p><em>1. 简单</em></p>
<p>HTTP 基本的报文格式就是 <code>header + body</code>，头部信息也是 <code>key-value</code> 简单文本的形式，<strong>易于理解</strong>，降低了学习和使用的门槛。</p>
<p><em>2. 灵活和易于扩展</em></p>
<p>HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员<strong>自定义和扩充</strong>。</p>
<p>同时 HTTP 由于是工作在应用层（ <code>OSI</code> 第七层），则它<strong>下层可以随意变化</strong>。</p>
<p>HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP/3 甚至把 TCP 层换成了基于 UDP 的 QUIC。</p>
<p><em>3. 应用广泛和跨平台</em></p>
<p>互联网发展至今，HTTP 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，HTTP 的应用遍地开花，同时天然具有<strong>跨平台</strong>的优越性。</p>
<h3 id="1-5-2-HTTP（1-1）-的缺点有哪些？"><a href="#1-5-2-HTTP（1-1）-的缺点有哪些？" class="headerlink" title="1.5.2 HTTP（1.1） 的缺点有哪些？"></a>1.5.2 HTTP（1.1） 的缺点有哪些？</h3><p>HTTP 协议里有优缺点一体的<strong>双刃剑</strong>，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。</p>
<p><em>1. 无状态双刃剑</em></p>
<p>无状态的<strong>好处</strong>，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。</p>
<p>无状态的<strong>坏处</strong>，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。</p>
<p>例如登录-&gt;添加购物车-&gt;下单-&gt;结算-&gt;支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。</p>
<p>这样每操作一次，都要验证信息，这样的购物体验还能愉快吗？别问，问就是<strong>酸爽</strong>！</p>
<p>对于无状态的问题，解法方案有很多种，其中比较简单的方式用 <strong>Cookie</strong> 技术。</p>
<p><code>Cookie</code> 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。</p>
<p>相当于，<strong>在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了了</strong>，</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-47-07.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p><em>2. 明文传输双刃剑</em></p>
<p>明文意味着在传输过程中的信息，是可方便阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。</p>
<p>但是这正是这样，HTTP 的所有信息都暴露在了光天化日下，相当于<strong>信息裸奔</strong>。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那<strong>你号没了</strong>。</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-47-50.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p><em>3. 不安全</em></p>
<p>HTTP 比较严重的缺点就是不安全：</p>
<ul>
<li>通信使用明文（不加密），内容可能会被窃听。比如，<strong>账号信息容易泄漏，那你号没了。</strong></li>
<li>不验证通信方的身份，因此有可能遭遇伪装。比如，<strong>访问假的淘宝、拼多多，那你钱没了。</strong></li>
<li>无法证明报文的完整性，所以有可能已遭篡改。比如，<strong>网页上植入垃圾广告，视觉污染，眼没了。</strong></li>
</ul>
<p>HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。</p>
<h3 id="1-5-3-HTTP-1-1-的性能如何？"><a href="#1-5-3-HTTP-1-1-的性能如何？" class="headerlink" title="1.5.3 HTTP/1.1 的性能如何？"></a>1.5.3 HTTP/1.1 的性能如何？</h3><p>HTTP 协议是基于 <strong>TCP/IP</strong>，并且使用了「<strong>请求 - 应答</strong>」的通信模式，所以性能的关键就在这<strong>两点</strong>里。</p>
<p><em>1. 长连接</em></p>
<p>早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。</p>
<p>为了解决上述 TCP 连接问题，HTTP/1.1 提出了<strong>长连接</strong>的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。</p>
<p>持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-48-13.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>当然，如果某个 HTTP 长连接超过一定时间没有任何数据交互，服务端就会主动断开这个连接。</p>
<p><em>2. 管道网络传输</em></p>
<p>HTTP/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。</p>
<p>即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以<strong>减少整体的响应时间。</strong></p>
<p>举例来说，客户端需要请求两个资源。以前的做法是，在同一个 TCP 连接里面，先发送 A 请求，然后等待服务器做出回应，收到后再发出 B 请求。那么，管道机制则是允许浏览器同时发出 A 请求和 B 请求，如下图：</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-48-30.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>但是<strong>服务器必须按照接收请求的顺序发送对这些管道化请求的响应</strong>。</p>
<p>注意，是按照服务端收到的请求顺序响应，并不管哪个请求是先发送的，假设客户端先发送 A 请求，后发送 B 请求，如果服务端先收到 B 请求，就先响应 B 请求，然后再响应 A 请求，但是假设处理 B 请求的时候，耗时比较长，那么请求 A 的响应就会被阻塞，这称为「队头堵塞」。</p>
<p>所以，<strong>HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞</strong>。</p>
<p><em>3. 队头阻塞</em> </p>
<p>「请求 - 应答」的模式加剧了 HTTP 的性能问题。</p>
<p>因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「<strong>队头阻塞</strong>」，好比上班的路上塞车。</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-48-51.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>总之 HTTP/1.1 的性能一般般，后续的 HTTP/2 和 HTTP/3 就是在优化 HTTP 的性能。</p>
<h2 id="1-6-HTTP-1-1、HTTP-2、HTTP-3-演变"><a href="#1-6-HTTP-1-1、HTTP-2、HTTP-3-演变" class="headerlink" title="1.6 HTTP/1.1、HTTP/2、HTTP/3 演变"></a>1.6 HTTP/1.1、HTTP/2、HTTP/3 演变</h2><h3 id="1-6-1-HTTP-1-1-相比-HTTP-1-0-提高了什么性能？"><a href="#1-6-1-HTTP-1-1-相比-HTTP-1-0-提高了什么性能？" class="headerlink" title="1.6.1 HTTP/1.1 相比 HTTP/1.0 提高了什么性能？"></a>1.6.1 HTTP/1.1 相比 HTTP/1.0 提高了什么性能？</h3><p>HTTP/1.1 相比 HTTP/1.0 性能上的改进：</p>
<ul>
<li>使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。</li>
<li>支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。</li>
</ul>
<p>但 HTTP/1.1 还是有性能瓶颈：</p>
<ul>
<li>请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 <code>Body</code> 的部分；</li>
<li>发送冗长的首部。每次互相发送相同的首部造成的浪费较多；</li>
<li>服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；</li>
<li>没有请求优先级控制；</li>
<li>请求只能从客户端开始，服务器只能被动响应。</li>
</ul>
<h3 id="HTTP-2-做了什么优化？"><a href="#HTTP-2-做了什么优化？" class="headerlink" title="HTTP/2 做了什么优化？"></a>HTTP/2 做了什么优化？</h3><p>HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-50-57.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>那 HTTP/2 相比 HTTP/1.1 性能上的改进：</p>
<p><em>1. 头部压缩</em></p>
<p>HTTP/2 会<strong>压缩头</strong>（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你<strong>消除重复的部分</strong>。</p>
<p>这就是所谓的 <code>HPACK</code> 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就<strong>提高速度</strong>了。</p>
<p><em>2. 二进制格式</em></p>
<p>HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了<strong>二进制格式</strong>，头信息和数据体都是二进制，并且统称为帧（frame）：<strong>头信息帧（Headers Frame）和数据帧（Data Frame）</strong>。</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-51-54.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这<strong>增加了数据传输的效率</strong>。</p>
<p>比如状态码 200 ，在 HTTP/1.1 是用 ‘2’’0’’0’ 三个字符来表示（二进制：110010 110000 110000），如图：</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-53-24.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>在 HTTP/2 是用数字 200 表示（二进制：11001000），如图：</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-54-06.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload><br><em>3. 数据流</em></p>
<p>HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。</p>
<p>在 HTTP/2 中每个请求或相应的所有数据包，称为一个数据流（<code>Stream</code>）。每个数据流都标记着一个独一无二的编号（Stream ID），<strong>不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ）</strong>，因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息</p>
<p>客户端和服务器<strong>双方都可以建立 Stream</strong>， Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。</p>
<p><img src="https://img-blog.csdnimg.cn/83445581dafe409d8cfd2c573b2781ac.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>客户端还可以<strong>指定数据流的优先级</strong>。优先级高的请求，服务器就先响应该请求。</p>
<p><em>4. 多路复用</em></p>
<p>HTTP/2 是可以在<strong>一个连接中并发多个请求或回应，而不用按照顺序一一对应</strong>。</p>
<p>移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，<strong>降低了延迟，大幅度提高了连接的利用率</strong>。</p>
<p>举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。 </p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-54-47.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p><em>5. 服务器推送</em></p>
<p>HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以<strong>主动</strong>向客户端发送消息。</p>
<p>比如，客户端通过 HTTP/1.1 请求从服务器那获取到了 HTML 文件，而 HTML 可能还需要依赖 CSS 来渲染页面，这时客户端还要再发起获取 CSS 文件的请求，需要两次消息往返，如下图左边部分：</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-55-06.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>如上图右边部分，在 HTTP/2 中，客户端在访问 HTML 时，服务器可以直接主动推送 CSS 文件，减少了消息传递的次数。</p>
<blockquote>
<p>HTTP/2 有什么缺陷？</p>
</blockquote>
<p>HTTP/2 通过 Stream 的并发能力，解决了 HTTP/1 队头阻塞的问题，看似很完美了，但是 HTTP/2 还是存在“队头阻塞”的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP 这一层。</p>
<p><strong>HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。</strong></p>
<p>举个例子，如下图：</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-55-36.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>图中发送方发送了很多个 packet，每个 packet 都有自己的序号，你可以认为是 TCP 的序列号，其中 packet 3 在网络中丢失了，即使 packet 4-6 被接收方收到后，由于内核中的 TCP 数据不是连续的，于是接收方的应用层就无法从内核中读取到，只有等到 packet 3 重传后，接收方的应用层才可以从内核中读取到数据，这就是 HTTP/2 的队头阻塞问题，是在 TCP 层面发生的。</p>
<p>所以，一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的<strong>所有的 HTTP 请求都必须等待这个丢了的包被重传回来</strong>。</p>
<h3 id="HTTP-3-做了哪些优化？"><a href="#HTTP-3-做了哪些优化？" class="headerlink" title="HTTP/3 做了哪些优化？"></a>HTTP/3 做了哪些优化？</h3><p>前面我们知道了 HTTP/1.1 和 HTTP/2 都有队头阻塞的问题：</p>
<ul>
<li>HTTP/1.1 中的管道（ pipeline）虽然解决了请求的队头阻塞，但是<strong>没有解决响应的队头阻塞</strong>，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等相应完这个请求后， 才能处理下一个请求，这属于 HTTP 层队头阻塞。</li>
<li>HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 ，但是<strong>一旦发生丢包，就会阻塞住所有的 HTTP 请求</strong>，这属于 TCP 层队头阻塞。</li>
</ul>
<p>HTTP/2 队头阻塞的问题是因为 TCP，所以 <strong>HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！</strong></p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-56-00.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>UDP 发生是不管顺序，也不管丢包的，所以不会出现像 HTTP/2 队头阻塞的问题</p>
<p>大家都知道 UDP 是不可靠传输的，但基于 UDP 的 <strong>QUIC 协议</strong> 可以实现类似 TCP 的可靠性传输。</p>
<p>QUIC 有以下 3 个特点。</p>
<p><em>1、无队头阻塞</em></p>
<p>QUIC 协议也有类似 HTTP/2 Stream 与多路复用的概念，也是可以在同一条连接上并发传输多个 Stream，Stream 可以认为就是一条 HTTP 请求。</p>
<p>QUIC 有自己的一套机制可以保证传输的可靠性的。<strong>当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题</strong>。这与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。</p>
<p>所以，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，某个流发生丢包了，只会影响该流，其他流不受影响。</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-58-06.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p><em>2、更快的连接建立</em></p>
<p>对于 HTTP/1 和 HTTP/2 协议，TCP 和 TLS 是分层的，分别属于内核实现的传输层、openssl 库实现的表示层，因此它们难以合并在一起，需要分批次来握手，先 TCP 握手，再 TLS 握手。</p>
<p>HTTP/3 在传输数据前虽然需要 QUIC 协议握手，这个握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。</p>
<p>但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层，而是QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS/1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商，如下图：</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-57-51.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></p>
<p>甚至，在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。</p>
<p><em>3、连接迁移</em></p>
<p>基于 TCP 传输协议的 HTTP 协议，由于是通过四元组（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接，那么<strong>当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立连接</strong>。而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延，以及 TCP 慢启动的减速过程，给用户的感觉就是网络突然卡顿了一下，因此连接的迁移成本是很高的。</p>
<p>而 QUIC 协议没有用四元组的方式来“绑定”连接，而是通过<strong>连接 ID</strong>来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了<strong>连接迁移</strong>的功能。</p>
<p>所以， QUIC 是一个在 UDP 之上的<strong>伪</strong> TCP + TLS + HTTP/2 的多路复用的协议。</p>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-07-06-19-57-32.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload><br>QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题，因为有的网络设备是会丢掉 UDP 包的，而 QUIC 是基于UDP 实现的，那么如果网络设备无法识别这个是 QUIC 包，那么就会当作 UDP包，然后被丢弃。</p>
<p>所以，HTTP/3 现在普及的进度非常的缓慢，不知道未来 UDP 是否能够逆袭 TCP。</p>
<hr>
<h2 id="1-1-HTTP-0-9"><a href="#1-1-HTTP-0-9" class="headerlink" title="1.1 HTTP/0.9"></a>1.1 HTTP/0.9</h2><ul>
<li>发送的时候会创建tcp连接 发送完毕后就关闭了，造成性能浪费</li>
<li>缺陷<ul>
<li>只能发送get请求， </li>
<li>不支持除了文本之外的内容 图片，css都不支持</li>
<li>不能识别访问者的身份</li>
</ul>
</li>
</ul>
<h2 id="1-2-HTTP-1-0"><a href="#1-2-HTTP-1-0" class="headerlink" title="1.2 HTTP/1.0"></a>1.2 HTTP/1.0</h2><ul>
<li>引入了 HTTP Header（头部）的概念，传输的数据，不再仅限于文本，可以解析图片音乐等</li>
<li>增加了响应状态码和 POST , HEAD 等请求方法</li>
</ul>
<h2 id="1-3-HTTP-1-1-纯文本协议"><a href="#1-3-HTTP-1-1-纯文本协议" class="headerlink" title="1.3 HTTP/1.1(纯文本协议)"></a>1.3 HTTP/1.1(纯文本协议)</h2><ul>
<li>基于tcp传输层，半双工通信（请求应答模式）。</li>
<li>http默认是无状态的(http1.1增加了cookie机制,可以用于识别用户身份)，没有序号，不保证按顺序传输，只是tcp那一层会给加上序号（默认tcp不能在没有应答完成后复用tcp通道继续发送消息）</li>
<li>TCP的连接和关闭非常耗时间，所以我们可以复用TCP创建的连接。HTTP/1.1响应中默认会增加 Connection:keep-alive（必须在一次请求应答后才能复用）(同样会造成tcp队头阻塞)</li>
<li>为了可以处理多个HTTP请求同时发送，内部还有管线化的特点，可以在同域名下同时发送多个请求(管线化的特点就是先发送先回来，依然会有队头阻塞的问题,这里指的是http中的队头阻塞),我们可以采用域名分片的，那么每个域名下都可以分配6个tcp通道，但是域名不易过多，会导致dns解析量太多的问题造成卡顿。</li>
<li>纯文本协议会有安全问题，在传输中明文传输 （http 现在使用最多的就是1.1 ）。 明文就会被别人篡改，对方也不知道这个数据有被更改过。因此使用tls来保证数据的可靠。 通过证书来保证数据不被篡改。</li>
</ul>
<h3 id="1-3-1-内容协商"><a href="#1-3-1-内容协商" class="headerlink" title="1.3.1 内容协商"></a>1.3.1 内容协商</h3><p>客户端和服务端进行协商，返回对应的结果<br>客户端Header    |服务端Header    |—<br>-|-|-<br>Accept|    Content-Type|    我发送给你的数据是什么类型<br>Accept-encoding    |Content- Encoding|    我发送给你的数据是用什么格式压缩 ( gzip 、 deflate 、 br )<br>Accept-language    |–|    根据客户端支持的语言返回 (多语言)<br>Range|Content-Range|    范围请求数据 206</p>
<h2 id="1-4-HTTP-2-0"><a href="#1-4-HTTP-2-0" class="headerlink" title="1.4 HTTP/2.0"></a>1.4 HTTP/2.0</h2><ul>
<li>使用 HPACK 算法压缩头部，减少数据传输量。</li>
<li>允许服务器主动向客户端推送数据，二进制协议可发起多个请求，使用时需要对请求加密通信。</li>
<li>多路复用，一条TCP链接来通信数据，把多个请求打碎成一个个帧，放到一条TCP中，减少了HTTP的队头阻塞。</li>
<li>TCP的队头阻塞时TCP本身的，所以HTTP2.0也无法解决</li>
</ul>
<h2 id="1-5HTTP-3-0"><a href="#1-5HTTP-3-0" class="headerlink" title="1.5HTTP/3.0"></a>1.5HTTP/3.0</h2><ul>
<li>基于 UDP 的 QUIC 协议。</li>
</ul>
<h2 id="1-6-HTTPS-保证密文-防止篡改"><a href="#1-6-HTTPS-保证密文-防止篡改" class="headerlink" title="1.6 HTTPS(保证密文+防止篡改)"></a>1.6 HTTPS(保证密文+防止篡改)</h2><ul>
<li>HTTPS = HTTP+SSL/TSL, SSL发展到 v3 时改名为 TLS 传输层安全，主要的目的是提供数据的完整性和保密性。<br><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/ikki-2022-05-10-15-40-56.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload></li>
</ul>
<h3 id="1-6-1-数据完整性"><a href="#1-6-1-数据完整性" class="headerlink" title="1.6.1 数据完整性"></a>1.6.1 数据完整性</h3><h4 id="1-6-1-1-摘要算法"><a href="#1-6-1-1-摘要算法" class="headerlink" title="1.6.1.1 摘要算法"></a>1.6.1.1 摘要算法</h4><ul>
<li>我们可以给内容增加一个摘要，传递到服务端后，再把内容做一次摘要，看下两次摘要内容是否一样</li>
<li>虽然我们可以通过摘要可以辨别内容是否有篡改，但是存在传输过程中摘要内拦截后修改。</li>
</ul>
<blockquote>
<p>我们可以在内容后面增加hash值进行传输，服务端收到后通过hash值来校验内容是否完整。数据是明文的显然不安全</p>
</blockquote>
<h3 id="1-6-2-数据加密"><a href="#1-6-2-数据加密" class="headerlink" title="1.6.2 数据加密"></a>1.6.2 数据加密</h3><h4 id="1-6-2-1-对称加密"><a href="#1-6-2-1-对称加密" class="headerlink" title="1.6.2.1 对称加密"></a>1.6.2.1 对称加密</h4><ul>
<li>加密和解密时使用的密钥都是同一个， 通信过程使用秘钥加密后的密文传输。只有自己 和网站才能解密。</li>
<li>缺点在接收密钥的过程中容易被拦截过去到密钥<br><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/%E5%AF%B9%E7%A7%B0%E5%8A%A0%E5%AF%86.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload alt="Image text"></li>
<li>目前 AES (Advanced Encryption Standard) ChaCha20 为最常见的对称加密算法</li>
</ul>
<h4 id="1-6-2-2-非对称加密"><a href="#1-6-2-2-非对称加密" class="headerlink" title="1.6.2.2 非对称加密"></a>1.6.2.2 非对称加密</h4><ul>
<li>发送方和接受方都有一个钥匙，发送方拿到公钥加密，接收方拿到私钥解密</li>
</ul>
<p>使用 RSA 、 ECDHE 算法解决秘钥交换的问题 （缺点是大量的建立连接，性能较差，会有中间人攻击问题）<br><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/%E9%9D%9E%E5%AF%B9%E7%A7%B0%E5%8A%A0%E5%AF%86.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload alt="Image text"></p>
<blockquote>
<p>最常听到的非对称加密算法是RSA、ECC(子算法 ECDHE 用于密钥交换，ECDSA 用 于数字签名)(性能和安全略胜一筹) HTTPS 中目前广泛使用 ECC 。</p>
</blockquote>
<h4 id="1-6-2-3-混合加密"><a href="#1-6-2-3-混合加密" class="headerlink" title="1.6.2.3 混合加密"></a>1.6.2.3 混合加密</h4><ul>
<li>对称+非对称（缺点是公钥是谁非给你的,没办法校验公钥的安全性）</li>
<li>非对 称解决密钥传输问题</li>
<li>对称 解决数据传输问题<br><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/%E6%B7%B7%E5%90%88%E5%8A%A0%E5%AF%861.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload alt="Image text"><br>这里还并不安全，还涉及到中间人攻击。（ 指攻击者与通讯的两端分别创建独立的联系,并交换其所收到的数据 ）<br><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/%E6%B7%B7%E5%90%88%E5%8A%A0%E5%AF%862.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload alt="Image text"></li>
</ul>
<h4 id="1-6-2-4-数字证书和CA"><a href="#1-6-2-4-数字证书和CA" class="headerlink" title="1.6.2.4 数字证书和CA"></a>1.6.2.4 数字证书和CA</h4><ul>
<li>操作系统和浏览器都内置了CA的公钥</li>
</ul>
<ol>
<li>浏览器访问服务器想要得到服务器的公钥，服务器将自己的公钥放入到CA数字证书中</li>
<li>由于CA数字证书内容过多，先将其进行摘要Hash，再采用CA私钥对hash值加密签名，返回给服务端。</li>
<li>服务端将CA证书返回给客户端，客户端再通过CA的公钥进行解密验证签名，并且获取到服务端的公钥。(如果有中间人，中间人也只能获取到服务端的公钥，哪怕篡改证书后也没有CA私钥进行加密签名，因此影响不到客户端)</li>
<li>客户端通过服务端的公钥创建会话密钥传送给服务端，服务端通过私钥解密出会话密钥的密文</li>
<li>双方再通过密文进行对称加密传输</li>
</ol>
<p><img src="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/network/http/CA.png" srcset="https://ikkiss.oss-cn-hangzhou.aliyuncs.com/images/myblog/loading.gif" lazyload alt="Image text"></p>
<blockquote>
<p>客户端会判断有效期、颁发者、证书是否被修改及证书是否被吊销。 每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证。</p>
</blockquote>
<ul>
<li>加密：对传输的数据进行加密。</li>
<li>数据一致性：保证传输过程中数据不会被篡改。</li>
<li>身份认证：确定对方的真实身份。</li>
</ul>
<h1 id="2-CDN"><a href="#2-CDN" class="headerlink" title="2.CDN"></a>2.CDN</h1><ul>
<li>CDN 的全称是Content Delivery Network，受制于网络的限制，访问者离服务器越远访<br>问速度就越慢</li>
<li>核心就是离你最近的服务器给你提供数据 （代理 + 缓存）<ul>
<li>先在全国各地架设 CDN 服务器</li>
<li>正常访问网站会通过 DNS 解析，解析到对应的服务器</li>
<li>解析1：我们通过 CDN 域名访问时，会被解析到 CDN 专用 DNS 服务器。并返回 CDN 全<br>局负载均衡服务器的 IP 地址。</li>
<li>解析2：向全局负载均衡服务器发起请求，全局负载均衡服务器会根据用户 IP 分配用<br>户所属区域的负载均衡服务器。并返回一台 CDN 服务器 IP 地址</li>
<li>用户向 CDN 服务器发起请求。如果服务器上不存在此文件。则向上一级缓存服务器请<br>求，直至查找到源服务器，返回结果并缓存到 DNS 服务器上。</li>
</ul>
</li>
</ul>
<h2 id="HTTP特点"><a href="#HTTP特点" class="headerlink" title="HTTP特点"></a>HTTP特点</h2><ul>
<li>http是不保存状态的协议，使用cookie来管理状态 (登录 先给你cookie 我可以看一下你有没有cookie)</li>
<li>为了防止每次请求都会造成无谓的tcp链接建立和断开，所以采用保持链接的方式 keep-alive</li>
<li>以前发送请求后需要等待并收到响应，才能发下一个，现在都是管线化的方式 (js css 可以并发请求 ）</li>
</ul>
<h1 id="2-HTTP状态码和常用方法"><a href="#2-HTTP状态码和常用方法" class="headerlink" title="2.HTTP状态码和常用方法"></a>2.HTTP状态码和常用方法</h1><h2 id="2-1状态码"><a href="#2-1状态码" class="headerlink" title="2.1状态码"></a>2.1状态码</h2><h2 id="2-2HTTP方法"><a href="#2-2HTTP方法" class="headerlink" title="2.2HTTP方法"></a>2.2HTTP方法</h2><ul>
<li>GET / POST / PUT /DELETE  增删改查  options 跨域的时候发送 预检请求</li>
<li>Resful风格  根据路径和不同的方法 就能确定对资源进行什么操作<ul>
<li>get /user  查询用户</li>
<li>post /user  添加用户</li>
<li>PUT /user  修改</li>
</ul>
</li>
</ul>
<p>options表示跨域的时候 会先检测是否ok ？ ok的话再去发送具体的数据<br>复杂请求才会发送options，常见的基本get和post就是简单请求，添加了自定义的头部就变成了了复杂请求了  只在跨域的时候使用</p>
<h2 id="客户端访问服务端的基本流程"><a href="#客户端访问服务端的基本流程" class="headerlink" title="客户端访问服务端的基本流程"></a>客户端访问服务端的基本流程</h2><ul>
<li>用户会输入一个网址  通过DNS解析服务端找到对应的ip地址</li>
<li>需要将数据传递给对方  http中存的是报文 （ 请求行 请求头 请求体）</li>
<li>tcp来发送数据   对数据进行拆包 而且添加了序号 （为了服务器收到之后可以进行数据的重组） 端口号 （tcp严重的缺陷队头阻塞，如果没有收到队头的数据，不会发送后续的内容）</li>
<li>发送的时候 需要通过ip地址进行寻址操作  边转发边发送  经历多个路由器  发快递 北京 -&gt; 南京 -》 杭州 -》 上海  （路由）</li>
<li>对方会根据 我们的数据进行重组 将数据拼接起来  最终服务器会响应客户端说 数据收到了  （响应行， 响应头，响应体）</li>
</ul>
<h2 id="http客户端和服务端通信"><a href="#http客户端和服务端通信" class="headerlink" title="http客户端和服务端通信"></a>http客户端和服务端通信</h2><p>Http报文，http交互的信息称之为http报文</p>

                
              </div>
            
            <hr/>
            <div>
              <div class="post-metas my-3">
  
    <div class="post-meta mr-3 d-flex align-items-center">
      <i class="iconfont icon-category"></i>
      

<span class="category-chains">
  
  
    
      <span class="category-chain">
        
  <a href="/categories/%E7%BD%91%E7%BB%9C%E7%9F%A5%E8%AF%86/" class="category-chain-item">网络知识</a>
  
  
    <span>></span>
    
  <a href="/categories/%E7%BD%91%E7%BB%9C%E7%9F%A5%E8%AF%86/HTTP/" class="category-chain-item">HTTP</a>
  
  

  

      </span>
    
  
</span>

    </div>
  
  
    <div class="post-meta">
      <i class="iconfont icon-tags"></i>
      
        <a href="/tags/%E7%BD%91%E7%BB%9C%E7%9F%A5%E8%AF%86/">#网络知识</a>
      
        <a href="/tags/HTTP/">#HTTP</a>
      
    </div>
  
</div>


              
  

  <div class="license-box my-3">
    <div class="license-title">
      <div>HTTP协议</div>
      <div>http://81.68.132.127/2022/10/07/network/http协议/</div>
    </div>
    <div class="license-meta">
      
        <div class="license-meta-item">
          <div>作者</div>
          <div>Ikki</div>
        </div>
      
      
        <div class="license-meta-item license-meta-date">
          <div>发布于</div>
          <div>2022年10月7日</div>
        </div>
      
      
        <div class="license-meta-item license-meta-date">
          <div>更新于</div>
          <div>2022年10月7日</div>
        </div>
      
      
        <div class="license-meta-item">
          <div>许可协议</div>
          <div>
            
              
              
                <a target="_blank" href="https://creativecommons.org/licenses/by/4.0/">
                  <span class="hint--top hint--rounded" aria-label="BY - 署名">
                    <i class="iconfont icon-by"></i>
                  </span>
                </a>
              
            
          </div>
        </div>
      
    </div>
    <div class="license-icon iconfont"></div>
  </div>



              
                <div class="post-prevnext my-3">
                  <article class="post-prev col-6">
                    
                    
                      <a href="/2022/10/17/react/basic/react-all-api/" title="react-api">
                        <i class="iconfont icon-arrowleft"></i>
                        <span class="hidden-mobile">react-api</span>
                        <span class="visible-mobile">上一篇</span>
                      </a>
                    
                  </article>
                  <article class="post-next col-6">
                    
                    
                      <a href="/2022/09/30/node/%E4%B8%80%E6%96%87%E6%90%9E%E5%AE%9A%E5%89%8D%E5%90%8E%E7%AB%AF%E9%89%B4%E6%9D%83/" title="最全前后端鉴权方案">
                        <span class="hidden-mobile">最全前后端鉴权方案</span>
                        <span class="visible-mobile">下一篇</span>
                        <i class="iconfont icon-arrowright"></i>
                      </a>
                    
                  </article>
                </div>
              
            </div>

            
  <article id="comments" lazyload>
    
  <div id="valine"></div>
  <script type="text/javascript">
    Fluid.utils.loadComments('#valine', function() {
      Fluid.utils.createScript('https://lib.baomitu.com/valine/1.5.1/Valine.min.js', function() {
        var options = Object.assign(
          {"appId":"6KzYWc2oaEBaHgNl4UIicMJC-gzGzoHsz","appKey":"vJ4FIwKeHRmHraCJraAsjyZ7","path":"window.location.pathname","placeholder":"请输入你的评论\n昵称为必填项目(输入QQ号码可以自动获取昵称和邮箱)\n虽然email不是必选，但是填写了email可以收到推送通知哦！","avatar":"retro","meta":["nick","mail","link"],"requiredFields":[],"pageSize":10,"lang":"zh-CN","highlight":true,"recordIP":true,"serverURLs":"","emojiCDN":null,"emojiMaps":null,"enableQQ":true},
          {
            el: "#valine",
            path: window.location.pathname
          }
        )
        new Valine(options);
        Fluid.utils.waitElementVisible('#valine .vcontent', () => {
          var imgSelector = '#valine .vcontent img:not(.vemoji)';
          Fluid.plugins.imageCaption(imgSelector);
          Fluid.plugins.fancyBox(imgSelector);
        })
      });
    });
  </script>
  <noscript>Please enable JavaScript to view the comments</noscript>


  </article>


          </article>
        </div>
      </div>
    </div>

    <div class="side-col d-none d-lg-block col-lg-2">
      

    </div>
  </div>
</div>





  



  



  



  



  







    

    
      <a id="scroll-top-button" aria-label="TOP" href="#" role="button">
        <i class="iconfont icon-arrowup" aria-hidden="true"></i>
      </a>
    

    
      <div class="modal fade" id="modalSearch" tabindex="-1" role="dialog" aria-labelledby="ModalLabel"
     aria-hidden="true">
  <div class="modal-dialog modal-dialog-scrollable modal-lg" role="document">
    <div class="modal-content">
      <div class="modal-header text-center">
        <h4 class="modal-title w-100 font-weight-bold">搜索</h4>
        <button type="button" id="local-search-close" class="close" data-dismiss="modal" aria-label="Close">
          <span aria-hidden="true">&times;</span>
        </button>
      </div>
      <div class="modal-body mx-3">
        <div class="md-form mb-5">
          <input type="text" id="local-search-input" class="form-control validate">
          <label data-error="x" data-success="v" for="local-search-input">关键词</label>
        </div>
        <div class="list-group" id="local-search-result"></div>
      </div>
    </div>
  </div>
</div>

    

    
  </main>

  <footer>
    <div class="footer-inner">
  
    <div class="footer-content">
      IKKI-专业BUG开发
    </div>
  
  
    <div class="statistics">
  
  

  
    
      <span id="busuanzi_container_site_pv" style="display: none">
        总访问量 
        <span id="busuanzi_value_site_pv"></span>
         次
      </span>
    
    
      <span id="busuanzi_container_site_uv" style="display: none">
        总访客数 
        <span id="busuanzi_value_site_uv"></span>
         人
      </span>
    
    
  
</div>

  
  
  
</div>

  </footer>

  <!-- Scripts -->
  
  <script  src="https://lib.baomitu.com/nprogress/0.2.0/nprogress.min.js" ></script>
  <link  rel="stylesheet" href="https://lib.baomitu.com/nprogress/0.2.0/nprogress.min.css" />

  <script>
    NProgress.configure({"showSpinner":false,"trickleSpeed":100})
    NProgress.start()
    window.addEventListener('load', function() {
      NProgress.done();
    })
  </script>


<script  src="https://lib.baomitu.com/jquery/3.6.0/jquery.min.js" ></script>
<script  src="https://lib.baomitu.com/twitter-bootstrap/4.6.1/js/bootstrap.min.js" ></script>
<script  src="/js/events.js" ></script>
<script  src="/js/plugins.js" ></script>


  <script  src="https://lib.baomitu.com/typed.js/2.0.12/typed.min.js" ></script>
  <script>
    (function (window, document) {
      var typing = Fluid.plugins.typing;
      var subtitle = document.getElementById('subtitle');
      if (!subtitle || !typing) {
        return;
      }
      var text = subtitle.getAttribute('data-typed-text');
      
        typing(text);
      
    })(window, document);
  </script>




  
    <script  src="/js/img-lazyload.js" ></script>
  




  
<script>
  Fluid.utils.createScript('https://lib.baomitu.com/tocbot/4.18.2/tocbot.min.js', function() {
    var toc = jQuery('#toc');
    if (toc.length === 0 || !window.tocbot) { return; }
    var boardCtn = jQuery('#board-ctn');
    var boardTop = boardCtn.offset().top;

    window.tocbot.init(Object.assign({
      tocSelector     : '#toc-body',
      contentSelector : '.markdown-body',
      linkClass       : 'tocbot-link',
      activeLinkClass : 'tocbot-active-link',
      listClass       : 'tocbot-list',
      isCollapsedClass: 'tocbot-is-collapsed',
      collapsibleClass: 'tocbot-is-collapsible',
      scrollSmooth    : true,
      includeTitleTags: true,
      headingsOffset  : -boardTop,
    }, CONFIG.toc));
    if (toc.find('.toc-list-item').length > 0) {
      toc.css('visibility', 'visible');
    }

    Fluid.events.registerRefreshCallback(function() {
      if ('tocbot' in window) {
        tocbot.refresh();
        var toc = jQuery('#toc');
        if (toc.length === 0 || !tocbot) {
          return;
        }
        if (toc.find('.toc-list-item').length > 0) {
          toc.css('visibility', 'visible');
        }
      }
    });
  });
</script>


  <script src=https://lib.baomitu.com/clipboard.js/2.0.11/clipboard.min.js></script>

  <script>Fluid.plugins.codeWidget();</script>


  
<script>
  Fluid.utils.createScript('https://lib.baomitu.com/anchor-js/4.3.1/anchor.min.js', function() {
    window.anchors.options = {
      placement: CONFIG.anchorjs.placement,
      visible  : CONFIG.anchorjs.visible
    };
    if (CONFIG.anchorjs.icon) {
      window.anchors.options.icon = CONFIG.anchorjs.icon;
    }
    var el = (CONFIG.anchorjs.element || 'h1,h2,h3,h4,h5,h6').split(',');
    var res = [];
    for (var item of el) {
      res.push('.markdown-body > ' + item.trim());
    }
    if (CONFIG.anchorjs.placement === 'left') {
      window.anchors.options.class = 'anchorjs-link-left';
    }
    window.anchors.add(res.join(', '));

    Fluid.events.registerRefreshCallback(function() {
      if ('anchors' in window) {
        anchors.removeAll();
        var el = (CONFIG.anchorjs.element || 'h1,h2,h3,h4,h5,h6').split(',');
        var res = [];
        for (var item of el) {
          res.push('.markdown-body > ' + item.trim());
        }
        if (CONFIG.anchorjs.placement === 'left') {
          anchors.options.class = 'anchorjs-link-left';
        }
        anchors.add(res.join(', '));
      }
    });
  });
</script>


  
<script>
  Fluid.utils.createScript('https://lib.baomitu.com/fancybox/3.5.7/jquery.fancybox.min.js', function() {
    Fluid.plugins.fancyBox();
  });
</script>


  <script>Fluid.plugins.imageCaption();</script>

  <script  src="/js/local-search.js" ></script>

  <script defer src="https://busuanzi.ibruce.info/busuanzi/2.3/busuanzi.pure.mini.js" ></script>




  
<script src="/fluid/js/star.js"></script>



<!-- 主题的启动项，将它保持在最底部 -->
<!-- the boot of the theme, keep it at the bottom -->
<script  src="/js/boot.js" ></script>


  

  <noscript>
    <div class="noscript-warning">博客在允许 JavaScript 运行的环境下浏览效果更佳</div>
  </noscript>
</body>
</html>
